Same, but I'd really like if if we could get an update on the status page before we read about outages in the press. I read https://9to5mac.com/2025/06/24/icloud-is-down-for-some-users-as-outage-impacts-photos-mail-more/ well before all the yellow & red dots on https://www.apple.com/support/systemstatus/, I wonder if we'll see some reporting on the impact of developer systems before https://developer.apple.com/system-status/ lights up

I am the user in question, so I guess I might as well chime in directly. let your customer set up a virtual machine and grant the Local Network privilege to their app there In this specific case, it's not a GUI application, it's a Python library, which has some multicast logic in it. Are you suggesting that the only option now is to block every test run on a user manually VNCing into a cloud CI backend to manually click on some GUI preferences? As you might imagine, this is not feasible either for an open source library that needs to accept volunteer contributions or a hosted CI service with ephemeral test runners. (The practical upshot of this is that we will need to treat macOS as a platform which can no longer support multicast sockets, which would be a bit of a bummer.)

I'd really recommend doing this sort of "fresh system" testing in a virtual machine. Thanks to Virtualization.framework there are a few cheap or free options, such as https://github.com/KhaosT/MacVM , https://apps.apple.com/us/app/utm-virtual-machines/id1538878817?mt=12 , and https://apps.apple.com/us/app/virtualos/id1614659226?mt=12 . It's a little slow but you can be sure that the OS install is totally fresh, very much like what you would expect a customer with nothing installed would have.

I noticed that @IBOutlet and @IBAction support appears to have quietly disappeared from Python in Xcode 13 as well. I was able to fix it in my case by creating fake Objective C or Swift classes which have the relevant named IBAction/IBOutlet names, and then just not including them in any build; just including the files in the project so Interface Builder can see them.

The question here says "HomeKit automations", but it sounds like the underlying problem is very specific to HomePod, and something being broken with its DNS resolution in "Get Contents of URL"? I found this question while searching for something else and was about to reply with my usual trick for getting LE certificates on LAN-only hostnames before realizing that you needed a cert for an IP address due to the HomePod/DNS issue :). Given that this would prevent you from retrieving any public HTTPS URL in this context, it seems like a straightforward bug that should be fixed on Apple's end - have you filed a Feedback for it?

Here's the mojang bug: https://bugs.mojang.com/browse/MCL-19830 . Please vote for it.